|
Microsoft® Script Debugger How Microsoft Script Debugger Works |
| Home |
|
For the most part, Microsoft® Script Debugger operates just like other debuggers. There are some notable differences, however.
Once you have installed the Microsoft Script Debugger, you can start it in one of three ways. In all three cases, you must start Microsoft Internet Explorer first. You can:
- Click Source on the View menu in Internet Explorer. Script Debugger starts, and opens the current HTML source file. This is the only way to start the debugger outside of a script. (When Script Debugger is not installed, clicking Source starts the Notepad editor.)
- Click Break at Next Statement on the Edit menu and then execute a script. The debugger starts, and stops at the first statement in the current script.
- Execute a Stop statement (VBScript) or debugger statement (JScript) in a script. Script Debugger opens, and stops at the statement.
If you haven't already, start the version of Internet Explorer supplied with this release and open Blend.htm in the Samples directory. Then Click Source on the View menu to start Script Debugger. In the Project Explorer window, three files are listed: Blend.htm, Picker.htm, and Table.htm.
Blend.htm is actually a frameset; the other two files are the content for the frames. When you open Table.htm, it displays the content that was generated by the UpdateColors function in Picker.htm. Clicking either the Start or End buttons in Internet Explorer causes the Table.htm file to be regenerated. When you reopen Table.htm, the contents have changed to reflect the current state of the pages.
The Break on Next Statement command is on both the Edit menu of Internet Explorer, and the Debug menu of Script Debugger. It is unique to script debugging. It informs Internet Explorer that the next time a script statement is executed, break. This is similar to a step command, except that you can use it when you are not currently executing a script.This command is the only way to debug scripts that are in the header of an HTML file. Choose Break on Next Statement from within Internet Explorer, or Script Debugger if it is running, and load the HTML page that contains the scripts to be debugged. Script Debugger stops on the first statement of the first script in the HTML file.
Unless you use the Break on Next Statement command to stop Script Debugger in the header of an HTML file, setting breakpoints in the header is useless. This is because the code in the header has already been executed by the time the HTML file has completed loading, and any breakpoints set after the HTML file has completed loading are lost when the page is refreshed.
Expression evaluation is handled by the scripting language engine, not by Script Debugger itself. Because of this, there can be delays in expression evaluation depending on what your script or system is doing.Also, you must use the language you are currently debugging for expression evaluation. For example, in the Color Blender sample there are both JScript and VBScript scripts. If you stop Script Debugger in a VBScript section of code and attempt to evaluate a JScript expression in the Immediate window, Script Debugger gives you an error.
Internet Explorer ceases communicating with scripting engines when it moves off a page containing scripts. It then reestablishes communication with the scripting engines if necessary for the next page. Because of this, debugging information may be lost at unexpected times.For example, say you set a breakpoint in a script on a page. If you then refresh the page in Internet Explorer, the following happens:
- Internet Explorer removes the current page from memory.
- If any scripting engines were loaded, communication to them ceases at this time. (This also causes breakpoints stored with those scripting engines to be lost as well.)
- The page is reloaded, and communication with scripting engines commences if necessary.
This means that you can't set a breakpoint in a script, refresh the page, and hit that breakpoint when the page is reloaded. The breakpoint will no longer be there. To perform a task like this, you must use the Break at Next Statement command previously described.
You can also see this behavior by putting a breakpoint in a generated file and regenerating that file. The Table.htm file in the Color Blender sample is a good example of this.